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REMARKS 
Claims 1-22 were considered in the Office Action. 

Claims 1-3, 7, 8, 10, 12, 15, 20, 21 and 22 have been amended. Support for these 
amendments is found at least in the specification at page 10, lines 17-24 and 32-33 and in 
originally filed claims 5 and 6. No new matter has been added. Claims 4-6, 18 and 19 have been 
cancelled. Claims 9, 1 1, 13, 14, 16, and 17 stand as originally filed. 

Claims 1-7, 10 and 12-22 stand rejected under 35 U.S.C 102(e) as being anticipated by 
Dray, U.S. Patent Application Publication No. 2002/0184485. Claim 8 stands rejected under 35 
U.S.C. 103(a) as being unpatentable over Dray in view of Mullen-Schultz, U.S. Patent No. 
6,393,462. Claim 9 stands rejected under 35 U.S.C. 103(a) as being unpatentable over Dray in 
view of Mullen-Schultz in fu66rther view of Odamura, U.S. Patent No. 6,763,248. Claim 1 1 
stands rejected under 35 U.S.C. 103(a) as being unpatentable over Dray in view of Hamilton, 
Heather, Online HTML Manual, "Creating Forms for Fun and Profit", 1999 (hereinafter 
Hamilton). 

Claim 2 stands rejected under 35 U.S.C. 1 12, second paragraph, and the specification is 
objected to for lack of basis for claim 2. Claim 2 has been amended as indicated by the 
Examiner, and Applicant believes that claim 2 as amended is clear and supported by the 
specification. 

Applicant believes that the currently pending claims are not anticipated by or obvious 
over the cited references for at least the reasons set forth below and respectfully requests 
reconsideration. 

The Invention of Claim 1 
The cited references do not disclose or suggest: 

"A method of electronically signing a hypertext markup language form page, comprising: 
loading said hypertext markup language form page into a browser application; 
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merging user-entered field values with said hypertext markup language form page 
to generate a merged page; and 

generating an electronic signature for said merged page from within said browser 
application." 

(Claim 1, as amended, emphasis added) 

The above highlighted features are not anticipated or suggested by the cited references 
and would not have been obvious to a person with ordinary skill in the art having the cited 
references. Dray does not disclose or suggest merging user-entered field values with a hypertext 
markup language (HTML) form page for electronic signature as in Applicant's claim 1. This 
merging of user-entered field values with an HTML form page is described in Applicant's 
specification at page 10, lines 17-23: 

"When the Store button 24 is pressed, the values entered in the form fields (e.g., 16 and 
20) are merged with the HTML source for the form 14, and the form 14 is prepared 
for signing. The user entered form field values are physically embedded into the 
original empty HTML form page." 

(Applicant's specification, page 10, lines 17-23, emphasis added) 

In contrast, Dray discloses that elements of a host document and user-entered information 
are gathered in a data structure in a "predefined sequence", (see Dray, paragraphs 58, 60 and 61) 
Dray indicates that the predefined sequence of the data structure is a "defined common format" 
that allows a Cipher Management Program to "reliably decompose the document into a 
consistent data structure for processing." (Dray, paragraph 40) Additional information about 
this predefined sequence may be found in Dray's Appendix A, page 36, in the comments to the 
"processlnput" function: 

"Here is the workhorse method of the applet: The params to this applet are the reference 
to the form and the concatenated form input as one string. This information will also 
be concatenated and signed." 
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(Dray, Appendix A, page 36, emphasis added) 

Dray does not merge "user-entered field values with said hypertext markup language 
form page to generate a merged page." Dray generates a data structure in which elements are 
arranged in an order other than that of the original HTML form. By merging user-entered field 
values with the HTML form page, Applicant's claim 1 prevents the possibility of tampering with 
a signed form by reordering fields in the blank form or in the database. 

Dray also discloses that only the form and form input are signed, as indicated in the 
comments to the "processlnput" function cited above. In contrast, claim 1 recites that the entire 
form page is signed, that is, the form and the page containing the form. By signing just the form 
and field values, Dray's host page is left vulnerable to tampering, which may substantially alter 
the meaning of the overall page even if the signed form content is unchanged. Text surrounding 
the form may be added that substantially alters the meaning of the form content, and new form 
objects could even be added to the page. The end user would not necessarily know what parts of 
the page had been signed. Furthermore, any scripts or applets in the page, including signature 
generation and verification code, would not be included in the signature unless included in the 
form object itself By merging << user-entered field values with said hypertext markup 
language form page to generate a merged page" that is then signed, claim 1 protects the entire 
page, including the form, the user-entered field values, and any other content in the page, in the 
order in which it appeared to the user when signed. 

For at least the reasons discussed above, Applicant believes that claim 1 is allowable over 
the cited reference and respectfully requests reconsideration. 

Dependent claims 2, 3 and 7-1 1 depend ultimately upon independent claim 1 which is 
allowable over the cited art as discussed above. These dependent claims are likewise in 
condition for allowance at least because they depend on an allowable independent claim. 
However, dependent claims 2, 3 and 7-1 1 are independently allowable at least in that they recite 
particular features which, when combined with the elements of the independent claim, are also 
not disclosed or suggested in the cited references. 
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The Invention of Claim 12 
The cited references do not disclose or suggest: 

"A method of verifying an electronic signature of a hypertext markup language form 
page, comprising: 

loading said hypertext markup language form page into a browser application, wherein 
said hypertext markup language form page comprises a merged page, said merged page 
comprising user-entered field values that have been merged into an associated form 
template; and 

generating an electronic signature for said merged page from within said browser 
application; and 

comparing said electronic signature with a stored electronic signature in said hypertext 
markup language form page." 

(Claim 12, as amended, emphasis added) 

Applicant repeats the arguments for allowability set forth above with respect to claim 1, 
but specifically directed to the method set forth in claim 12. As discussed above, Dray does not 
disclose or suggest creating a merged page in which user-entered field values have been merged 
into an associated form template. Dray also does not disclose or suggest generating an electronic 
signature for a merged page. Rather, Dray generates an electronic signature for a bitstream made 
up of a data structure which, as discussed above, contains elements from an HTML form and 
field values stored in a predetermined order. Dray indicates that after a form has been filled out 
by a user and a signature has been generated as described above for the data structure made up of 
elements of a form and user-entered fields, the "user-entered text and signature" are returned 
to the vendor's web server. (Dray, paragraphs 73, 74) To verify the signature, the original 
document and user-entered text would have to be reassembled into a data structure to generate 
the signature for comparison. Dray clearly does not load a signed merged page into a browser for 
signature verification, because Dray does not transmit a merged page. Dray transmits only user- 
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entered text and a signature. That user-entered text would have to be reunited with the original 
form from some other source for signature verification. Again, this illustrates the difference 
between Dray's approach of generating a database to be signed, rather than generating a merged 
page that is self-contained, including both the original source page and the user-entered field 
values that have been physically embedded into the source page. Applicant believes that claim 
12 is allowable over the cited references and respectfully requests reconsideration. 

Dependent claims 13-14 depend upon independent claim 12 which is allowable over the 
cited art as discussed above. These dependent claims are likewise in condition for allowance at 
least because they depend on an allowable independent claim. However, dependent claims 13-14 
are independently allowable at least in that they recite particular features which, when combined 
with the elements of the independent claim, are also not disclosed or suggested in the cited 
references. 

The Invention of Claim 15 
The cited references do not disclose or suggest: 

"An apparatus for electronically signing a hypertext markup language form page, 
comprising: 

a. one or more computer readable storage media; and 

b. computer executable program code stored in the one or more computer readable 
storage media, the computer executable program code comprising: 

i. code for loading and displaying said hypertext markup language form 

page; 

ii. code for merging user-entered field values with said hypertext 
markup language form page to generate a merged page; 

iii. code for generating an electronic signature for said merged page from 
within a browser; and 

iv. code for verifying an electronic signature attached to said merged page." 



10 



Serial No.: 10/028,886 

(Claim 15, as amended, emphasis added) 

Applicant repeats the arguments for allowability set forth above with respect to claims 1 
and 12, but specifically directed to the apparatus set forth in claim 15. 

Claim 16 is believed allowable as depending from an allowable base claim and is further 
believed allowable in that the cited references do not disclose or suggest: 

"The apparatus of claim 15, wherein said code for generating said electronic signature 
comprises plugin code for said browser." 

(Claim 16, emphasis added) 

Applicant respectfully disagrees that Dray discloses the limitations of claim 16. In 
particular, Dray, paragraph 73, indicates that the signature processing program is "provided to the 
user's computer as part of the form." Dray's code for generating an electronic signature appears 
to be code that is embedded in a form, and is not plugin code for a browser. 

Dependent claim 17 depends upon independent claim 12 which is allowable over the 
cited art as discussed above. This dependent claim is likewise in condition for allowance at least 
because it depends on an allowable independent claim. However, dependent claim 17 is 
independently allowable at least in that it recites particular features which, when combined with 
the elements of the independent claim, are also not disclosed or suggested in the cited references. 

Claim 20 is believed allowable as depending from an allowable base claim and is further 
believed allowable in that the cited references do not disclose or suggest: 

"The apparatus of claim 15, wherein said code for merging said user-entered field 
values does not interfere with posting of said at least one field to a server 
application." 

(Claim 20, as amended, emphasis added) 
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Applicant repeats the arguments for allowability set forth above with respect to claim 1, 
but specifically directed to the apparatus set forth in claim 20. As discussed above, Dray does 
not disclose or suggest merging user-entered field values in an HTML form page. 

Claim 21 is believed allowable as depending from an allowable base claim and is further 
believed allowable in that the cited references do not disclose or suggest: 

"The apparatus of claim 15, wherein said code for verifying said electronic signature 
comprises: 

1 . code for generating a new electronic signature for said merged page; and 

2. code for comparing said new electronic signature with said electronic signature 
attached to said merged page." 

(Claim 21, as amended, emphasis added) 

Applicant repeats the arguments for allowability set forth above with respect to claim 1, 
but specifically directed to the apparatus set forth in claim 21 . 

Claim 22 is believed allowable as depending from an allowable base claim and is further 
believed allowable in that the cited references do not disclose or suggest: 

"The apparatus of claim 15, wherein said code for loading and displaying said hypertext 
markup language form page displays said hypertext markup language form page in a 
first frame and displays at least one user interface button in a second frame, said at 
least one user interface button for initiating said code for generating said electronic 
signature and said code for verifying said electronic signature." 
(Claim 22, as amended, emphasis added) 

Although Dray does disclose "Sign/Submit" and "Verify" buttons, Dray does not disclose 
or suggest that the HTML form page is displayed in a first frame and at least one user interface 
button is displayed in a second frame. The term "frame" does not appear in the Dray reference. 
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Dray indicates that the buttons are elements of the document. (Dray, paragraphs 37 and 89) 
Dray's HTML document must therefore be designed or modified to contain signature buttons, 
rather than allowing any HTML page to be signed without modification. 

In view of the above, all of the claims are believed to be in condition for allowance, and 
the Applicant respectfully requests that a timely Notice of Allowance be issued. 



Respectfully submitted, 



Alan D. Kirsch 
Registration No. 33,720 
Attorney for Applicants 
P.O. Box 1625 

Idaho Falls, Idaho 83415-3899 
(208) 526-9140 
(208) 526-8339 FAX 
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